The present invention relates to the fields of distributed computing systems, client server computing and object-oriented programming. More specifically, the present invention teaches methods and apparatus for managing a database within a distributed object operating environment.
Object oriented programming methodologies have received increasing attention over the past several years in response to the growing tendency for software developed using traditional programming methods to be delivered late and over budget. This stems from the fact that traditional programming techniques that emphasize procedural models and "linear" code tend to be difficult to design and maintain in many circumstances. Generally, large programs created using traditional methods are "brittle." That is, even small changes can effect numerous elements of the programming code. Thus, minor changes made to the software in response to user demands can require major redesign and rewriting of the entire program.
Object oriented programming strategies tend to avoid these problems because object methodologies focus on manipulating data rather than procedures; thus providing the programmer with a more intuitive approach to modeling real world problems. In addition objects encapsulate related data and procedures so as to hide that information from the remainder of the program by allowing access to the data and procedures only through the object's interface. Hence changes to the data and/or procedures of the object are relatively isolated from the remainder of the program. This provides code that is more easily maintained as compared to code written using traditional methods, as changes to an object's code do not affect the code in the other objects. In addition, the inherent modular nature of objects allows individual objects to be reused in different programs. Thus, programmers can develop libraries of "tried and true" objects that can be used over and over again in different applications. This increases software reliability while decreasing development time, as reliable programming code may be used repeatedly.
A more recent advance in the field of object oriented methodologies has been the implementation of distributed object operating environments over computers interconnected via a computer network. As used herein, the term "distributed object" or "object" refers to an encapsulated package of code and data that can be manipulated by operation through an interface. Thus, distributed objects will be seen by those skilled in the art of object oriented programming (OOP) as including the basic properties that define traditional programming objects. However, distributed objects differ from traditional programming objects by the inclusion of two important features. First, distributed objects are multilingual. That is, the interfaces of distributed objects are defined using an interface definition language (IDL) that can be mapped to a variety of different programming languages. One such interface definition language is Object Management Group's IDL. Second, distributed objects are location-independent, i.e., distributed objects can be located anywhere in a network. This contrasts sharply with traditional programming objects which typically exist in a single address space.
Distributed objects can be object clients or object servers, depending upon whether they are sending requests to other objects or replying to requests from clients. In a distributed object operating environment, requests and replies are made through an Object Request Broker (ORB) that is aware of the locations and status of the objects. One architecture which is suitable for implementing such an ORB is provided by the Common Object Request Broker Architecture (CORBA) specification. The CORBA specification was developed by the Object Management Group (OMG) to define the distributed computing environment world in terms of objects in a distributed client-server environment, where server objects are capable of providing services to clients requesting the service. In the following discussion, the terms "object" and "distributed object" will be used interchangeably.
As will be appreciated by those skilled in the art, objects may be broken down (figuratively) into two components: code and state. Code is essentially the executable computer instructions by which the object operates. State is thus the remaining portion of the object such as data which is not code. In general, most objects require some type of persistence strategy for maintaining their state. In explanation, a persistence strategy is the mechanism by which objects manage their state, enabling objects to systematically perform operations on their state such as reading, writing, deleting, and changing. By way of example, a document object will need a persistence strategy to maintain its text in some type of permanent, mass storage device.
In prior solutions, objects were required to implement their own persistent storage mechanism or rely on a multiple client database implemented by their host computer operating system. (Note that databases are by definition persistent.) In the first persistence strategy, each object maintains its own, distinct database. As a result, each object needs code specifically directed towards database management, code which is otherwise not related to the purpose of the object and thus an undue burden on the programmer. Furthermore, as will be appreciated by those skilled in the art, each distinct database will have a minimum amount of overhead (such as file descriptors and allocated blocks of memory which may not be utilized). Hence this system is inefficient in terms of resource utilization, both in system resources and program development time.
In the second persistence strategy the database is a multiple client database able to accept data write operations from multiple clients. As will be appreciated by those skilled in the art, the multiple client database is a more sophisticated database and therefore requires additional programming and system resources. For example, the multiple client database manager must use multiple buffers and also assert locks on unique portions of the database. Then the database manager must assure that any changes occur to the database systematically. To do this, the database manager must define a single sequence of actions which provide a consistent result. As will be appreciated by those skilled in the art, this "serialization" requirement is a difficult task.
Thus current solutions provide two possible persistent strategies, neither of which are quite satisfactory. On the one hand, if a multiple client database is implemented, the cost in terms of system resources is expensive, as multiple buffers must be used and unique portions of the database reserved for single users. On the other hand, if each client maintains its own database, the system resources are not utilized efficiently as the overhead for each database is redundant. Furthermore, the programmer of each client must perform the additional coding for the database. This is not only a waste of programming resources, it is an unsound strategy. As discussed previously, one of the goals of OOP is to refine techniques and develop tried and true objects. But in this case, each object is required to perform the redundant task of database management and each time this task is done presents yet another opportunity for error. What is needed is a method for multiple clients to act as a single user of a database. This method should further require a minimum of client resources directed towards the database. Furthermore, since the database will be accessed by multiple clients, the persistence strategy must include sophisticated mechanisms and apparatus for synchronizing the different data write operations.